home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-rare-nap-x500naming-00.txt
< prev
next >
Wrap
Text File
|
1993-10-04
|
47KB
|
1,197 lines
Internet Draft P. Barker
Expires: April 1994 University College London
S.E. Kille
ISODE Consortium
T. Lenggenhager
SWITCH
October 1993
Naming and Structuring Guidelines for X.500 Directory Pilots
<draft-rare-nap-x500naming-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
Deployment of a Directory will benefit from following certain
guidelines. This document defines a number of naming and
structuring guidelines focused on White Pages usage.
Alignment to these guidelines is recommended for directory pilots.
The final version of this document will replace RFC 1384.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 1]
Internet Draft X.500 Naming Guidelines October 1993
Table Of Contents
1 Introduction ................................................. 2
2 DIT Structure ................................................ 2
2.1 Structure Rules ......................................... 2
2.2 The Top Level of the DIT ................................ 3
2.3 Countries ............................................... 4
2.4 Organisations ........................................... 4
2.5 Multinational Organisations ............................. 5
2.6 Organizational Roles .................................... 8
3 Naming Style ................................................. 9
3.1 National Guidelines for Naming .......................... 9
3.2 Naming Organisation and Organisational Unit Names ....... 9
3.3 Naming Human Users ...................................... 10
3.4 Application Entities .................................... 11
4 Attribute Values ............................................. 11
4.1 Basic Attribute Syntaxes ................................ 11
4.2 Languages & Transliteration ............................. 12
4.3 Access control .......................................... 13
4.4 Selected Attributes .................................... 14
5 Miscellany .................................................. 19
5.1 Schema consistency of aliases .......................... 19
5.2 Organisational Units ................................... 20
6 References .................................................. 20
1 Introduction
As a pre-requisite to this document, it is assumed that the COSINE
and Internet X.500 Schema is followed [1].
2 DIT Structure
The majority of this document is concerned with DIT structure,
naming and the usage of attributes for organisations, organisational
units and personal entries.
This section briefly notes three other key issues.
2.1 Structure Rules
A DIT structure is suggested in Annex B of X.521 [2], and it is
recommended that Directory Pilots for White Pages services should
follow these guidelines. Some simple restrictions should be applied,
as described below. For further usage of the Directory like
e-mail routing with the Directory or storage of network information
in the Directory it will be necessary to follow the guidelines
specified in the respective documents.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 2]
Internet Draft X.500 Naming Guidelines October 1993
One of the few exceptions to the basic DIT structure is, that
international organisations will be stored immediately under the root
of the tree. Multi-national organisations will be stored within the
framework outlined, but with some use of aliases and attributes such
as seeAlso to help bind together the constituent parts of these
organisations. This is discussed in more detail in section 2.5.
2.2 The Top Level of the DIT
The following information will be present at the top level of the
DIT:
Participating Countries
According to the standard the RDN is the ISO 3166 country code [3].
In addition, the entries should contain suitable values of the
friendlyCountryName attribute specified in RFC 1274. Use of this
attribute is described in more detail in section 4.4.4.
International Organisations
An international organisation is an organisation, such as the
United Nations, which inherently has a brief and scope covering
many nations. Such organisations might be considered to be
supra-national and this, indeed, is the raison-d'etre of such
organisations. Such organisations will almost all be governmental
or quasi-governmental. A multi-national organisation is an
organisation which operates in more than one country, but is not
supra-national. This classification includes the large commercial
organisations whose production and sales are spread throughout a
large number of countries.
International organisations may be registered at the top level.
This will not be done for multi-national organisations. Currently
three organisations are registered so far: Inmarsat, Internet and
North Atlantic Treaty Organization. This is not a formal
registration, but is adopted for the Internet Directory Service.
Localities
A few localities will be registered under the root. The chief
purpose of these locality entries is to provide a "natural" parent
node for organisations which are supra-national, and yet which do
not have global authority in their particular field. Such
organisations will usually be governmental or quasi-governmental.
Example localities might include: Europe, Africa, West Indies.
Example organisations within Europe might include: European Court
of Justice, European Space Agency, European Commission.
DSA Information
Some information on DSAs may be needed at the top level. This
should be kept to a minimum.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 3]
Internet Draft X.500 Naming Guidelines October 1993
The only directory information for which there is a recognised top
level registration authority is countries. Registration of other
information at the top level may potentially cause problems. At this
stage, it is argued that the benefit of limited additional top level
registrations outweighs these problems. However, this potential
problem should be noted by anyone making use of such a registration.
2.3 Countries
The national standardization bodies will define national guidelines
for the structure of the national part of the DIT. In the interim,
the following simple structure should suffice.
The country entry will appear immediately beneath the root
of the tree. Organisations which have national significance should
have entries immediately beneath their respective country entries.
Smaller organisations which are only known in a particular locality
should be placed underneath locality entries representing states or
similar geographical divisions. Entry for private persons will be
listed under the locality entries. An example plan evolving for the
US is the work of the North American Directory Forum [4].
2.4 Organisations
Large organisations will probably need to be sub-divided by
organisational units to help in the disambiguation of entries for
people with common names. Entries for people and roles will be
stored beneath organisations or organisational units.
The structure of an organisation changes considerably over time, the
structure of the DIT however should be as stable as possible.
Changing the structure implies the change of the DNs of the entries.
This may be disrupt the user service because alias entries, seeAlso
attribute values but also personal alias references stored in
preference files of user interfaces use the DN as reference to the
original entry. These references are one-way only and the Directory
standard offers no support to automatically update all references to
an entry once its DN changes.
2.4.1 Depth of tree
The broad recommendation is that the DIT should be as flat as
possible. A flat tree means that Directory names will be relatively
short, and probably somewhat similar in length and component
structure to paper mail addresses. A deep DIT would imply long
Directory names, with somewhat arbitrary component parts, with a
result which it is argued seems less natural. Any artificiality in
the choice of names militates against successful querying.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 4]
Internet Draft X.500 Naming Guidelines October 1993
A presumption behind this style of naming is that most querying will
be supported by the user specifying convenient strings of characters
which will be mapped onto powerful search operations. The
alternative approach of the user browsing their way down the tree and
selecting names from large numbers of possibilities may be more
appropriate in some cases, and a deeper tree facilitates this.
However, these guidelines recommend a shallow tree, and implicitly a
search oriented approach.
It may be considered that there are two determinants of DIT depth:
first, how far down the DIT an organisation is placed; second, the
structure of the DIT within organisations.
The structure of the upper levels of the tree will be determined in
due course by various registration authorities, and the pilot will
have to work within the given structure. However, it is important
that the various pilots are cognisant of what the structures are
likely to be, and move early to adopt these structures.
The other principal determinant of DIT depth is whether an
organisation splits its entries over a number of organisational
units, and if so, the number of levels. The recommendation here is
that this sub-division of organisations is kept to a minimum. A
maximum of two levels of organisational unit should suffice even for
large organisations. Organisations with only a few tens or hundreds
of employees should strongly consider not using organisational units
at all. It is noted that there may be some problems with choice of
unique RDNs when using a flat DIT structure. Multiple component
RDNs can alleviate this problem. The standard X.521 recommends that
an organizationalUnitName attribute can also be used as a naming
attribute to disambiguate entries [2]. Further disambiguation may be
achieved by the use of a personalTitle or userid attribute in the RDN.
2.4.2 Real World Organisational Structure
Another aspect on designing the DIT structure for an organisation is
the administrative structure within a company. Using the same
structure in the DIT might help in distributing maintenance authority
to the different units. Please note comments on the stability of the
DIT structure in section 2.4.
2.5 Multinational Organisations
The standard says that only international organisations may be placed
under the root of the DIT. This implies that multi-national
organisations must be represented as a number of separate entries
underneath country or locality entries. This structure makes it more
awkward to use X.500 within a multi-national to provide an internal
organisational directory, as the data is now spread widely throughout
the DIT, rather than all being grouped within a single sub-tree.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 5]
Internet Draft X.500 Naming Guidelines October 1993
Many people have expressed the view that this restriction is a severe
limitation of X.500, and argue that the intentions of the standard
should be ignored in this respect. This note argues, though, that
the standard should be followed.
No attempt to precisely define multinational organisation is essayed
here. Instead, the observation is made that the term is applied to a
variety of organisational structures, where an organisation operates
in more than one country. This suggests that a variety of DIT
structures may be appropriate to accommodate these different
organisational structures. This document suggests three approaches,
and notes some of the characteristics associated with each of these
approaches.
Before considering the approaches, it is worth bearing in mind again
that a major aim in the choice of a DIT structure is to facilitate
querying, and that approaches which militate against this should be
avoided wherever possible.
2.5.1 The multi-national as a single entity
ROOT
/ | \
/ | \
C=GB C=FR C=US
/ | \
/ | \
O=MultiNat---->O=MultiNat<----O=MultiNat
/ | \
/ | \
/ | \
l=abc ou=def l=fgi
---> means "alias to"
Figure 1: The multi-national as a single entity
In many cases, a multi-national organisation will operate with a
highly centralised structure. While the organisation may have large
operations in a number of countries, the organisation is strongly
controlled from the centre and the disparate parts of the
organisation exist only as limbs of the main organisation. In such a
situation, the model shown in figure 1 may be the best choice. The
organisation's entries all exist under a single sub-tree. The
organisational structure beneath the organisation entry should
reflect the perceived structure of the organisation, and so no
recommendations on this matter can be made here. To assist the
person querying the directory, alias entries should be created for
all countries where the organisation operates.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 6]
Internet Draft X.500 Naming Guidelines October 1993
2.5.2 The multi-national as a loose confederation
Another common model of organisational structure is that where a
multi-national consists of a number of national entities, which are
in large part independent of both sibling national entities, and of
any central entity. In such cases, the model shown in Figure 2 may
be a better choice. Organisational entries exist within each country,
and only that country's localities and organisational units appear
directly beneath the appropriate organisational entry. Some binding
together of the various parts of the organisation can be achieved by
the use of aliases for localities and organisational units, and this
can be done in a highly flexible fashion. In some cases, the
national view might not contain all branches of the company, as
illustrated in Figure 2.
ROOT
/ | \
/ | \
C=GB C=FR C=US
/ | \
/ | \
O=MultiNat O=MultiNat O=MultiNat
/ | / | \ | \
/ | / | \ | \
L=FR L=GB<----L=GB | L=US---->L=US L=FR
\ | /
------------------->L=FR<----------------
---> means "alias to"
Figure 2: The multi-national as a loose confederation
2.5.3 Loosely linked DIT Sub-trees
A third approach is to avoid aliasing altogether, and to use the
looser binding provided by an attribute such as seeAlso. This
approach treats all parts of an organisation as essentially separate.
A unified view of the organisation can only be achieved by user
interfaces choosing to follow the seeAlso links. This is a key
difference with aliasing, where decisions to follow links may be
specified within the protocol. (Note that it may be better to
specify another attribute for this purpose, as seeAlso is likely to
be used for a wide variety of purposes.)
Barker, Kille & Lenggenhager Expires: April 1994 [Page 7]
Internet Draft X.500 Naming Guidelines October 1993
2.5.4 Summary of advantages and disadvantages of the above approaches
Providing an internal directory
All the above methods can be used to provide an internal
directory. In the first two cases, the linkage to other parts of
the organisation can be followed by the protocol and thus
organisation-wide searches can be achieved by single X.500
operations. In the last case, interfaces would have to "know" to
follow the soft links indicated by the seeAlso attribute.
Impact on naming
In the single-entity model, all DNs within the organisation will
be under one country. It could be argued that this will often
result in rather "unnatural" naming. In the loose-confederation
model, DNs are more natural, although the need to disambiguate
between organisational units and localities on an international,
rather than just a national, basis may have some impact on the
choice of names. For example, it may be necessary to add in an
extra level of organisational unit or locality information. In
the loosely-linked model, there is no impact on naming at all.
Views of the organisation
The first method provides a unique view of the organisation. The
loose confederacy allows for a variety of views of the
organisation. The view from the centre of the organisation may
well be that all constituent organisations should be seen as part
of the main organisation, whereas other parts of the organisation
may only be interested in the organisation's centre and a few of
its sibling organisations. The third model gives an equally
flexible view of organisational structures.
Lookup performance
All methods should perform reasonably well, providing information
is either held within a single DSA or it is replicated to the other
DSAs.
2.6 Organizational Roles
Entries with an object class of Organizational Role should be used to
represent role information, such as secretaries, postmasters and
directory managers. Creating separate entries for important roles
makes this information more visible than it would be by simply
assigning descriptive information using attributes of personal entries.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 8]
Internet Draft X.500 Naming Guidelines October 1993
3 Naming Style
The first goal of naming is to provide unique identifiers for
entries. Once this is achieved, the next major goal in naming entries
should be to facilitate querying of the Directory. In particular,
support for a naming structure which facilitates use of user friendly
naming [5] is desirable. Other considerations, such as accurately
reflecting the organisational structure of an organisation, should be
disregarded if this has an adverse effect on normal querying. Early
experience in the pilot has shown that a consistent approach to
structure and naming is an aid to querying using a wide range of user
interfaces, as interfaces are often optimised for DIT structures
which appear prevalent.
In addition, the X.501 standard notes that "RDNs are intended to
be long-lived so that the users of the Directory can store the
distinguished names of objects..." and "It is preferable that
distinguished names of objects which humans have to deal with be
user-friendly." [2]
Naming is dependent on a number of factors and these are now
considered in turn.
3.1 National Guidelines for Naming
Where naming is being done in a country which has established
guidelines for naming, these guidelines should in general be
followed. These guidelines might be based on an established
registration authority, or may make use use of an existing
registration mechanism (e.g., company name registration).
Where an organisation has a name which is nationally registered in an
existing registry, this name is likely to be appropriate for use in
the Directory, even in cases where there are no national guidelines.
3.2 Naming Organisation and Organisational Unit Names
The naming of organisations in the Directory will ultimately come
under the jurisdiction of official naming authorities. In the
interim, it is recommended that pilots and organisations follow these
guidelines. An organisation's RDN should usually be the full name of
the organisation, rather than just a set of initials. This means
that University College London should be preferred over UCL. An
example of the problems which a short name might cause is given by
the proposed registration of AA for the Automobile Association. This
seems reasonable at first glance, as the Automobile Association is
well known by this acronym. However, it seems less reasonable in a
broader perspective when you consider that organisations such as
Alcoholics Anonymous and American Airlines use the same acronym.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 9]
Internet Draft X.500 Naming Guidelines October 1993
Just as initials should usually be avoided for organisational RDNs,
so should formal names which, for example, exist only on official
charters and are not generally well known. There are two reasons
for this approach:
1. The names should be meaningful.
2. The names should uniquely identify the organisation, and be a
name which is unlikely to be challenged in an open registration
process. For example, UCL might well be challenged by United
Carriers Ltd.
The same arguments on naming style can be applied with even greater
force to the choice of RDNs for organisational units. While
abbreviated names will be in common parlance within an organisation,
they will almost always be meaningless outside of that organisation.
While many people in academic computing habitually refer to CS when
thinking of Computer Science, CS may be given several different
interpretations. It could equally be interpreted as Computing
Services, Cognitive Science, Clinical Science or even Counselling
Services.
For both organisations and organisational units, extra naming
information should be stored in the directory as alternative values
of the naming attribute. Thus, for University College London, UCL
should be stored as an alternative organizationName attribute value.
Similarly CS could be stored as an alternative organizationalUnitName
value for Computer Science and any of the other departments cited
earlier. In general, entries will be located by searching, and so it
is not essential to have RDNs which are either the most memorable or
guessable, although names should be recognisable. The need for users
not to type long names may be achieved by use of carefully selected
alternative values.
3.3 Naming Human Users
A reasonably consistent approach to naming people is particularly
critical as a large percentage of directory usage will be looking up
information about people. User interfaces will be better able to
assist users if entries have names conforming to a common format, or
small group of formats. It is suggested that the RDN should follow
such a format. Alternative values of the common name attribute
should be used to store extra naming information. It seems sensible
to try to ensure that the RDN commonName value is genuinely the most
common name for a person as it is likely that user interfaces may
choose to place greater weight on matches on the RDN than on matches
on one of the alternative names.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 10]
Internet Draft X.500 Naming Guidelines October 1993
The choice of RDN for humans will be influenced by cultural
considerations. In many countries the best choice will be of the
form familiar-first-name surname. Thus, Steve Kille is preferred as
the RDN choice for one of this document's co-authors, while Stephen E.
Kille is stored as an alternative commonName value. Pragmatic choices
will have to be made for other cultures.
The common name attribute should not be used to hold other attribute
information such as telephone numbers, room numbers, or local codes.
Such information should be stored within the appropriate attributes as
defined in the COSINE and Internet X.500 Schema. If such attributes
have to be used to disambiguate entries, multi-component RDNs should be
used, such that other attribute(s) be used for naming in addition to a
common name. More details on the use of commonName in section 4.4.1.
The choice of a naming strategy should not be made on the basis of
the possibilities of the currently available user interface
implementations. For example, it is inappropriate to use common
names of the form 'surname firstname' merely because a user interface
presents results in a more satisfactory order by so doing.
Use the best structure for human names, and fix the user interface!
3.4 Application Entities
The guidelines of X.521 should be followed, in that the application
entity should always be named relative to an Organisation or
Organisational Unit. The application process will often correspond
to a system or host. In this case, the application entities should
be named by Common Names which identify the service (e.g., "FTAM
Service"). In cases where there is no useful distinction between
application process and application entity, the application process
may be omitted (This is often done for DSAs in the current pilot).
4 Attribute Values
In general the attribute values should be used as documented in the
standards. Sometimes the standard is not very precise in which
attribute to use and how to represent a value.
The following sections give recommendations how to use them in X.500
pilot projects.
4.1 Basic Attribute Syntaxes
Every attribute type has a definition of the attribute syntaxes its
values may be use. Most attribute types make use the basic attribute
syntaxes only.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 11]
Internet Draft X.500 Naming Guidelines October 1993
4.1.1 Printable String
This most simple syntax uses only characters from ISO 646 IRV.
A-Z a-z 0-9 ( ) +
, - . / : ? space
Tab 1: Characters in PrintableString
4.1.2 Teletex String - T.61 [6]
The Teletex character set is a very unusual one in the computing
environment because it uses mixed one and two octet character codes
which are more difficult to handle than single octet codes. Most
of the characters can be mapped to the more often supported 8bit
character set standard ISO 8859-1 (ISO Latin-1). [7]
4.1.3 Case Ignore String
Many attributes use this case insensitive syntax. It allows
attribute values to be represented using a mixture of upper and
lower case letters, as appropriate. Matching of attribute values,
however, is performed such that no significance is given to case.
4.1.4 Distinguished Name
A Distinguished Name should never contain a value in T.61 string
syntax because many users would not be able to view or type it
correctly by lack of appropriate HW/SW configuration.
Therefore, only the characters defined in printable string syntax
should be used as part of a RDN.
4.2 Languages & Transliteration
The standard as available has no support at all for the use of
different languages in the Directory. It is e.g. not possible
to add a language qualifier to a description attribute nor is it
possible to use characters beyond the Teletex character set.
4.2.1 Languages other than English
Many countries have more than one national language and a world-wide
Directory must be able to support non-English-speaking users.
Until the standard provides a solution for this problem it is possible
to make use of multi-valued attributes to specify a value not only in
the local languages but also in English.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 12]
Internet Draft X.500 Naming Guidelines October 1993
In particular the friendlyCountry, state and locality attributes should
use the most often used translations of its original value to
increase the chance for successful searches also for users with a
foreign language. Other attributes like description, organization
and organizationalUnit attributes should provide multi-lingual values
where appropriate.
The drawback of this solution is, that the user interfaces present
much redundant information because they are not able to know the
language of the values and make an automatic selection.
Note: The sequence of multi-valued attribute values in an entry
cannot be defined. It is always up to the DSA to decide on
which order to store them and return them as results, and to
the DUA to decide on which order to display them.
4.2.2 Transliteration
What measures can be taken to make sure all users are able read an
attribtue, when a value uses one of the special characters from the
T.61 character set? An interim solution is transliteration as used
in earlier days with the typewriters, where e.g. the German 'a'
with umlaut is written as 'ae'. Transliteration is not necessarily
unique since it is dependent on the language, English speakers
transliterate the 'a' with umlaut just to an 'a'. However, it is an
improvement over just using the T.61 value since it may not be possible
to display such a value at all.
Whenever an attribute needs a character not in PrintableString and
the attribute syntax allows the use of the T.61 character set, it is
recommended that the attribute should be supplied as multi-valued
attribute both in T.61 string and in a transliterated PrintableString
notation.
4.3 Access control
An entry's object class attribute, and any attribute(s) used for
naming an entry are of special significance and may be considered to
be "structural". Any inability to access these attributes will often
militate against successful querying of the Directory. For example,
user interfaces typically limit the scope of their searches by
searching for entries of a particular type, where the type of entry
is indicated by its object class. Thus, unless the intention is to
bar public access to an entry or set of entries, the object class and
naming attributes should be publicly readable.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 13]
Internet Draft X.500 Naming Guidelines October 1993
4.4 Selected Attributes
The section lists attributes together with a short description what
they should be used for and some examples. The source of the
attributes is given in brackets. [8]
4.4.1 Personal Attributes
commonName [X.520]
It is proposed that pilots should ignore the standard's
recommendations on storing personal titles, and letters indicating
academic and professional qualifications within the commonName
attribute, as this overloads the commonName attribute.
A personalTitle attribute has already been specified in the COSINE
and Internet Schema, and another attribute could be specified for
information about qualifications.
The choice of a name depends on the culture as discussed in section
3.3. When a commonName is selected as (part of) a RDN the most often
used form of the name should be selected. A firstname should never
be supplied only as an initial (unless, of course, the source data does
not include forenames). It is very important to have its full value in
order to be able to distinguish between two similar entries. Sets of
initials should not be concatenated into a single "word", but be
separated by spaces and/or "." characters.
Format: Firstname [Initials] Lastname
Example: Steve Kille
Stephen E. Kille
S.E. Kille
The use of 'Lastname Firstname' is deprecated as explained in
section 3.3.
favouriteDrink [RFC 1274]
This is an attribute type every user may set to a value of his
choice (when given modification access to the entry). It is an
example of the possibilities provided by the Directory Service
to expand its purpose beyond mere communication related attributes.
Example: Pure Crystal Water
organizationalStatus [RFC 1274]
The Organisational Status attribute type specifies a category by
which a person is often referred to in an organisation. Examples
of usage in academia might include undergraduate student,
researcher, lecturer, etc.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 14]
Internet Draft X.500 Naming Guidelines October 1993
A Directory administrator should probably consider carefully the
distinctions between this and the title and description attributes.
Example: undergraduate student
personalTitle [RFC 1274]
The usually used titles, especially academic ones. Excessive use
should be avoided.
Example: Prof. Dr.
roomNumber [RFC 1274]
The room where the person works, it will mostly be locally defined
how to write the room number, e.g. Building Floor Room.
Example: HLW B12
secretary [RFC 1274]
The secretary of the person. This is the Distinguished Name (DN) of
the secretary.
Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
surname [X.520]
Like with commonName it is a matter of culture what to use for
surname in case of a noble name, e.g. de Stefani, von Gunten.
Example: Kille
title [X.520]
Title describing the position, job title or function of an
organizational person.
Example: Manager - International Sales
userId [RFC 1274]
When an organisation has centrally managed user ids, it might make
sense to include it into the entry. It might also be used to form
a unique RDN for the person.
Example: skille
userPassword [X.520]
The password of the entry which allows the modification of the entry,
provided that the Access Control List (ACL) permits it. The password
should not be the same as any system password, unless it is sure that
Barker, Kille & Lenggenhager Expires: April 1994 [Page 15]
Internet Draft X.500 Naming Guidelines October 1993
nobody can read it. With the current implementations this is mostly
not guaranteed.
Example: 8kiu8z7e
4.4.2 Organisational Attributes
associatedDomain [RFC 1274]
The Internet domain name for an organization or an organizationalUnit.
Example: isode.com
businessCategory [X.520]
Type of business an organization, organizationalUnit or
organizationalPerson is involved in.
Example: Software Development
organization [X.520]
The name of the organization. The value for the RDN should be
chosen according to section 3.2. Additional names like
abbreviations should be used for better search results.
Example: Uni Bern
Universite de Berne
Universitaet Bern
University of Berne
unibe
organizationalUnit [X.520]
The name of a part of the organization. The value for the RDN
should be chosen according to section 3.2. Additional names like
should be provided for better search results.
Example: Institut fuer Angewandte Mathematik
Mathematik
iam
roleOccupant [X.520]
The person(s) in that role. This is the Distinguished Name of the
entry of the person(s).
Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
searchGuide [X.520]
The currently available DUAs do not use this attribute.
It seems that it is not powerful enough for real usage.
Therefore, it is of not much use to define it.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 16]
Internet Draft X.500 Naming Guidelines October 1993
4.4.3 Locale Attributes
locality [X.520]
Name of the place, village or town with values in local and other
languages as useful.
Example: Bale
Basel
Basilea
Basle
stateOrProvinceName [X.520]
Name of the canton, county, department, province or state with
values in local and other languages as useful.
Example: Ticino
Tessin
4.4.4 Miscellenious Attributes
audio [RFC 1274]
The audio attribute uses a u-law encoded sound file as used by
the "play" utility on a Sun 4. According to RFC 1274 it is an
interim format. It may be useful to listen to the pronounciation
of a name which is otherwise unknown.
description [X.520]
A short explanation of the function or special interests of a
person or organization. Overlap between description, organizational
status and title should be avoided.
Example: Expert for OSI applications.
# Again this overlaps with title.
friendlyCountryName [RFC 1274]
The friendlyCountryName attribute type specifies names of countries
in human readable format. Especially the country name as used in the
major languages should be included as additional values to help
foreign users.
jpegPhoto [RFC 1488]
A color or grayscale picture encoded according to JPEG File
Interchange Format (JFIF). Thanks to compression the size of the
pictures is moderate. For persons it may show a portrait, for
organisations the company logo or a map on how to get there.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 17]
Internet Draft X.500 Naming Guidelines October 1993
photo [RFC 1274]
The photo attribute is a b/w or grayscale G3 fax encoded picture
for an object. The size of the photo should be in a sensible
relation to the informational value of it. This attribute will
be replaced by jpegPhoto.
seeAlso [X.520]
Reference to another closely related entry in the DIT, e.g. from
a room to the person using that room. It is the Distinguished
Name of the entry.
Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
4.4.5 MHS Attributes
mhsORAddresses [X.411] [9]
The attribute uses internally an ASN.1 structure. The string notation
used for display purposes is implementation dependent. This
attribute is especially useful for an integrated X.400 user agent
since it gets the address in a directly usable format.
rfc822mailbox [RFC 1274]
E-Mail address in RFC 822 notation
Example: S.Kille@ISODE.com
textEncodedORAdress [RFC 1274]
X.400 e-mail address in string notation. The F.401 notation should be
used [10]. This attribute shall disappear once the majority of the DUAs
support the mhsORAddresses attribute. The advantage of the latter
attribute is, that a configurable DUA could adjust the syntax to the
one needed by the local mailer, where textencodedORAddress is just a
string which will mostly have a different syntax than the mailer
expects.
Example: G=thomas; S=lenggenhager; OU1=gate; O=switch;
P=switch; A=arcom; C=ch;
4.4.6 Postal Attributes
postalAddress [X.520]
The full postal address (but not including the name) in international
notation, with up to 6 lines with 30 characters each.
Example: SWITCH
Limmatquai 13
CH-8001 Zurich
Barker, Kille & Lenggenhager Expires: April 1994 [Page 18]
Internet Draft X.500 Naming Guidelines October 1993
postalCode [X.520]
The postalCode will be the same as used in the postalAddress
(in international notation).
Example: CH-8001
streetAddress [X.520]
It shall be the street where the person has its office. Mostly, it
will be the street part of the postalAddress.
Example: Limmatquai 138
4.4.7 Telecom Attributes
telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520]
The phone number in the international notation according to
CCITT E.123. The separator '-' instead of space may be used
according to the local habit, it should be used consistently
within a contry.
Format: "+" <country code> <national number> ["x" <extension>]
Example: +41 1 268 1540
telexNumber [X.520]
The telex number in the international notation
Example: number: 817379, country: ch, answerback: ehhg
5 Miscellany
This section draws attention to two areas which frequently provoke
questions, and where it is felt that a consistent approach will be
useful.
5.1 Schema consistency of aliases
According to the letter of the standard, an alias may point at any
entry. It is beneficial for aliases to be 'schema consistent'.
The following two checks should be made:
1. The Relative Distinguished Name of the alias should be a valid
Relative Distinguished Name of the entry.
2. If the entry (aliased object) were placed where the alias is,
there should be no schema violation.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 19]
Internet Draft X.500 Naming Guidelines October 1993
5.2 Organisational Units
There is a problem that many organisations can be either
organisations or organisational units, dependent on the location in
the DIT (with aliases giving the alternate names). For example, an
organisation may be an independent national organisation and also an
organisational unit of a parent organisation. To achieve this, it is
important to allow an entry to be of both object class organisation
and of object class organisational unit.
6 References
[1] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
X.500 schema. Request for Comments RFC 1274, Department of
Computer Science, University College London, November 1991.
[2] The Directory --- Overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[3] ISO 3166 Country Codes.
[4] The North American Directory Forum. A Naming Scheme for C=US,
September 1991. Also NADF-175.
[5] S.E. Hardcastle-Kille. Using the OSI Directory to achieve
user friendly naming. RFC 1484, Department of Computer Science,
University College London, July 1993.
[6] ISO Latin-1.
[8] P. Barker. Preparing data for inclusion in an X.500 Directory.
Research Note RN/92/41, Department of Computer Science, University
College London, May 1992.
[9] CCITT X.400 Series Recommendations.
[10] CCITT F.400 Series Recommendations.
Security Considerations
Security issues are not substantially discussed in this memo.
Barker, Kille & Lenggenhager Expires: April 1994 [Page 20]
Internet Draft X.500 Naming Guidelines October 1993
Authors' Addresses
Paul Barker
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone:+44-71-380-7366
EMail: P.Barker@CS.UCL.AC.UK
DN: CN=Paul Barker, OU=Computer Science,
O=University College London, C=GB
UFN: Paul Barker, Computer Science, UCL, GB
Steve Kille
ISODE Consortium
P.O. Box 505
London
SW11 1DX
England
Phone:+44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille, O=ISODE Consortium, C=GB
UFN: S. Kille, ISODE Consortium, GB
Thomas Lenggenhager
SWITCH
Limmatquai 138
CH-8001 Zurich
Switzerland
Phone:+41-1-268-1540
EMail: Lenggenhager@SWITCH.CH
DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH
UFN: Thomas Lenggenhager, SWITCH, CH
Barker, Kille & Lenggenhager Expires: April 1994 [Page 21]
